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SNMP over IPX 


Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 

Abstract 


This memo defines a convention for encapsulating Simple Network 
Management Protocol (SNMP) [1] packets over the transport mechanism 
provided via the Internetwork Packet Exchange (IPX) protocol [2]. 


Editor’s Note 


As stated below and in reference [5], it is strongly advised that for 
interoperability, SNMP be implemented over UDP/IP and not directly on 
media or other protocols (such as IPX). 


1. Introduction 


The SNMP protocol has been specified as the official network 
management protocol of the Internet. Its widespread acceptance and 
implementation by developers, both inside and outside the Internet 
community, is fostering synergetic growth to a variety of protocols 
and platforms. 


This memo addresses the use of SNMP over the IPX protocol, which has 
become quite widespread principally due to the popularity of Novell 
NetWare. Roughly equivalent to UDP in function, IPX provides 
connectionless, unacknowledged datagram service over a variety of 
physical media and protocols. 


Although modifications have been made elsewhere in the NetWare 
protocol suite, IPX is identical to the Xerox Internet Datagram 
Protocol (IDP) [3]. The socket address space authority is 
administered by Novell. 


The use of SNMP over the UDP transport [4] is today the common mode 


of operation in the Internet. This specification may be appropriate 
for some environments in which UDP transport services are not 
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available. SNMP implementors should be aware that the choice of 
underlying transport may have a significant impact on the 
interoperability and ubiquity of the management capability in the 
Internet. Considerations relevant to choosing a transport for use 
with SNMP are described in [5]. 


Specification 


SNMP packets will always set the Packet Type field in the IPX header 
to 4 (i.e., Packet Exchange Packet). 


1 Socket Assignments 


SNMP protocol entities will receive GetRequest-PDU, GetNextRequest-— 
PDU, and SetRequest-PDU messages on socket 36879 (Destination Socket 
field set to hexadecimal 900F), and Trap-PDU messages on socket 36880 
(Destination Socket field set to hexadecimal 9010). 


GetResponse-PDU messages will be addressed to the IPX address and 
socket from which the corresponding GetRequest-PDU, GetNextRequest-— 
PDU, or SetRequest-PDU originated. 


-2 Maximum Packet Length 


Although SNMP does not require conformant implementations to accept 
messages whose length exceed 484 bytes, it is recommended that 
implementations support a maximum SNMP message size of 546 bytes (the 
maximum size allowed under IPX). Furthermore, this limit is the 
maximum packet length guaranteed to traverse IPX routers which do not 
provide fragmentation. Implementors may choose to use longer packet 
lengths if the maximum is known, which depends on the intermediate 
routers and/or intermediate datalink layer protocols. 


3 The agent-addr Field for the Trap-PDU 


The agent-addr field in a Trap-PDU emitted by an SNMP agent should 
contain the IpAddress 0.0.0.0. An SNMP manager may ascertain the 
source of the trap by querying the transport layer. 


4 IPX Transport Address Representation 


There are occasions when it is necessary to represent a transport 
service address in a MIB. For instance, the SNMP party MIB [6] uses 
an OBJECT IDENTIFIER to define the transport domain (IP, IPX, etc.) 
and an OCTET STRING to represent an address within that domain. The 
following definitions are provided for use in such a scheme. 
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RFC1298-MIB DEFINITIONS ::= BEGIN 
IMPORTS 
enterprises FROM RFC1155-SMI; 
novell OBJECT IDENTIFIER = { enterprises 23 } 
transportDomains OBJECT IDENTIFIER = { novell 7 } 
ipxTransportDomain OBJECT IDENTIFIER ::= { transportDomains 1 } 


-- Authoritatively names the IPX Transport Domain 
IpxTransportAddress ::= OCTET STRING (SIZE (12) ) 


—-- A textual convention denoting a transport service address in 
-—- the ipxTransportDomain. An IpxTransportAddress is 12 octets 
-- long and comprises 3 fields, each in network-byte (high-low) 
-- order. 


-—- The first field is 4 octets long and contains the network 
—- number. 


—- The next field is 6 octets long and contains the physical 
-- address of the node. Since IPX can run over a variety of 
-—- subnet architectures, the physical node address may not 
-—- require all 6 octets. As specified in [2], the physical 
-—- node address will occupy the least significant portion of 
-—- the field and the most significant octets should be set 
SS to zero. 


—- The last field is 2 octets long and contains the socket 
—- number. 


END 
Sis Document Procurement 


This section provides contact points for procurement of selected 
documents. 


A complete description of IPX may be secured at the following 
address: 


Novell, Inc. 

122 East 1700 South 
P. O. Box 5900 

Provo, Utah 84601 USA 
800 526 5463 
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Novell Part # 883-000780-001 

The specification for IDP (part of XNS) may be ordered from: 
Xerox System Institute 
475 Oakmead Parkway 
Sunnyvale, CA 94086 
Attn: Fonda Pallone 
(415) 813-7164 
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5. Security Considerations 


Security issues are not discussed in this memo. 
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